Great work! One thing that comes to my mind after looking at this: Could other print moves be included as well? Maybe for an advanced version this might be user configurable or a drop down like "only adjust external perimeters / all perimeters / only infill / all print moves"?

Thanks a lot. Yes we can apply this to other moves as well. It’s up to us users to decide where this would be beneficial.

Just for reference, the full version of this, with minimum layer time taking into account this filter, is being worked on. Not much left but it took some time because I had to rewrite some existing stuff due to technical reasons.

Great work, thank you for the effort, looking forward to test it!

cosmetic change:
change the exclude_print_speed_ranges to coFloats (ConfigOptionFloats) with a default with two values.
then on the gui, you should be able to modify by :

		setting:label$Min:id$0:exclude_print_speed_ranges
        setting:label$Max:id$1:exclude_print_speed_ranges

now you don't need the split_user_input_ranges_to_individual_strings, just get the first and second value (after verifying they exists)

Yes, I think also it should be applied to all moves.

What is your strategy for the minimum layer time? As it's a post-processing, i guess if it slow something down into the forbidden band, it slow it down to the min?

Hey Meril.
I just happened to have finished the minimum layer time integration today. I’ll send you the branch with a short explanation when I get back home shortly.

Alright. Here is the diff, branch is this one.

I rewrote the cooling algorithm. Modifying the existing one does not make sense as it hardly extendable and not easy to maintain at all.

The new algorithm (NewCoolingBuffer) treats all lines as a collection. It sums their length and calculates the speed they ALL should have in order to reach the minimum layer time. That's what the existing one does as well.
The main difference in mine is that we then check if this speed falls in an illegal range, adjusts it according to the "adjustment direction", and corrects all non-external perimeter lines' speeds to get as close as possible to the minimum layer time (thus decreasing print times). It does not go above their existing speed, obviously.

If we want to apply the filter in more extrusion types we have to rewrite the algorithm, but that's not too difficult due to my code structure. We have to touch but one function. With a day of thinking I can go through some ideas I had on this. But my idea for now was to do shorter releases to get feedback from users and developers. External perimeters only could be one such release.

Alternatively, we can apply a stupid easy filter after the original algorithm. This would work for all extrusion types with ~10 lines of effort. Check revision b449e6e which does just that.

Working examples.

• Minimum layer time: 15 seconds
• Original external perimeter speed: 20mm/s
• Exclude range: 4-20mm/s
  Adjustment option is "Highest" for 1st pic, "Lowest" for 2nd
  Notice the external perimeter speed following the adjustment direction, and all other extrusions being adjusted separately.
  

Ignore the 14seconds, that's a rounding issue.

Notes:

• The algorithm is not computationally perfect; A more complex algorithm can be written but is complex, ugly, and doesn't give too many benefits. In my opinion, we shouldn't have too many layers where slowdown is enabled. Instead we should as always fill the buildplate with more parts.

I'll look this week-end.

Alright. Here is the diff, branch is this one.

note: if you move/update your branchchka.master.exclude-velocity, the new commit will be showed here.

cosmetic change:
change the exclude_print_speed_ranges to coFloats (ConfigOptionFloats) with a default with two values.
then on the gui, you should be able to modify by :

From what I see by implementing this, it assumes a single exclusion range, no? Except if I'm missing something. I made this support multiple excluded ranges on purpose, because our vibration graphs can look like this:

There's more than one regions to exclude, my printer's graphs also had more than one regions I want to exclude.

note: if you move/update your branchchka.master.exclude-velocity, the new commit will be showed here.

I'm not doing that yet because we might decide to not include those changes, so I'm keeping this branch clean. I will squash those commits anyways, that was my original plan. Let me know what you think about the new algorithm.